报告引言

AI 安全形势

2025 年的 AI 安全领域呈现出一种割裂的局面：解决方案所针对的问题本身模糊不清。

风投驱动的营销热潮在社交媒体上引发了普遍的困惑，围绕应用场景和最佳实践都存在重大误解。本报告旨在拨开迷雾，澄清在所谓的“AI-TRiSM”混沌中被掩盖的关键信息。

AI 信任、风险和安全治理（AI Trust, Risk, and Security Management）这一类别本意是将一系列解决方案归入同一标签下，但它常常抹平了不同工具间的重要区别——尤其是供应商解决的问题类型及其解决方式。

大部分 AI 安全问题看似新颖，但其许多潜在挑战我们早已熟悉。 在几乎所有细分领域，现有工具都提供了与各种初创公司相似的功能。虽然这可能暗示安全团队应该等待采用新的解决方案，但传统供应商要赶上更专业的 AI 原生产品的步伐仍需时日。

与任何安全决策一样，正确的选择很大程度上取决于三个因素：

• • 组织特定的风险状况
• • 技术栈
• • 组织优先级

读完本报告后，您将获得两大收获：

• • 清楚了解何时及为何使用 AI 安全工具，包括这些工具旨在解决哪些具体应用场景。
• • 对当前该领域的供应商进行结构化概述，包括他们提供的服务以及如何根据您的需求评估他们。

我们还将提供一个简单的决策流程图，以帮助您根据实际场景指导工具选择。

AI 应用场景

首先，我们概述不同的 AI 安全场景。这些应用场景可以分为四大类：

顺便提一下，可以主张存在第五个类别，即围绕 AI 关注点的策略和合规性管理，但我们选择将其排除在本报告之外。这是一个较小的应用场景，通常与安全工程师关系不大。

风险类型

每类 AI 工具都为防御特定风险而设计的。在终端用户数据方面，工具保护员工终端免受操纵，或阻止员工向未经授权的 AI 系统共享未经授权的材料。

在安全态势方面，安全团队难以深入了解模型的开发和部署方式，以及这些模型可以访问哪些数据集。虽然许多团队依赖第三方模型，但自托管模型尤其容易受到不同的投毒或供应链攻击。此外，模型也可能像任何其他代码包一样存在漏洞。

最后，运行时应用安全在现实世界攻击中面临的风险最大，尤其是在系统连接到内部数据之后。AI 应用的早期迭代风险较低，因为它们只是将用户的数据呈现给用户自己；然而，随着智能体（agent）代表用户执行操作并访问敏感数据，智能体架构已迅速增加了风险。

终端用户数据管控

了解员工 AI 使用情况 是大多数企业开始其 AI 安全之旅的地方。自然的起点是监控和控制敏感数据输入到第三方模型。在采用 AI 的早期，尚不清楚托管在 HuggingFace 等平台上的模型会成为标准，还是像 ChatGPT 和 Claude 这样的专有选项会占主导地位。随着时间的推移，情况变得明朗，大多数员工倾向于选择少数几个选项——通常是他们的办公AI 工具，如 Microsoft Co-Pilot 或 Gemini，或 ChatGPT。

该类别的核心安全问题包括：

• • 监控与第三方工具共享的敏感数据
• • 确保这些工具已配置为不使用敏感数据进行训练
• • 检测可疑行为（例如用户遭受提示词注入攻击）

随着特定 AI 工具的成熟，它们的应用场景也在演变。例如，Cursor 被广泛用于代码生成，而 Microsoft Copilot 在企业无代码 AI 应用方面获得了关注。

对于 Microsoft Copilot 等工具，主要关注点是权限管理。用户可能在不知情的情况下有权访问敏感数据，或创建了具有比预期更广泛权限的应用程序，然后 AI 可以利用这些权限来获取特权数据。这凸显了对更严格的SaaS 身份和访问管理 日益增长的需求。

对于安全代码生成（通常通过 Cursor），许多组织已经接受了其带来的生产力提升，尽管存在将代码暴露给第三方模型的安全权衡。现在的重点已经转向维护代码质量 并确保 AI 生成的代码符合组织标准。

总结来说，终端用户数据管控围绕三个关键子类别展开：

1. 1. 通过 AI 聊天机器人实现数据防泄露
2. 2. 生产力平台中 AI 工具的SaaS 访问控制
3. 3. 安全代码创建，特别是面向如 Cursor这样面向开发者的工具时

AI 安全态势管理

这第二类别侧重于保护支持 AI 本身的基础设施。与第一类别类似，随着公司开始标准化部署模式，它也在迅速发展。在早期阶段，组织混合使用本地 Hugging Face 模型、开源替代方案以及来自 OpenAI 和 Anthropic 等供应商的云托管模型。随着时间的推移，基于 API 的模型因其性能优势而变得更加普遍。主要的例外涉及为节省成本而托管本地模型的团队，以及利用 LangChain 等框架创建智能体架构。

像 Wiz 这样的 CNAPP 供应商很早就认识到了这一领域的机会，并创造了AI 安全态势管理 (AI Security Posture Management, AI-SPM) 这一术语。起初，它指的是发现功能，帮助组织识别正在使用的模型及其部署位置。但后来扩展到包括 AI 开发生命周期管理，包括监控 Jupyter notebooks、Airtable 管道以及其他超越 EC2 实例的复杂工作流。

此层的风险主要是错误配置 和对模型的未授权访问。一个显著的例子是 Oligo Security 发现的 PyTorch 漏洞，它展示了配置错误的 AI 服务如何成为被主动利用的威胁。

另一个新兴的关注点是模型投毒 和供应链完整性。这导致了围绕“ML BOM”（机器学习物料清单）的标准化，与“AI BOM”互换使用，以帮助跟踪和授权模型来源。Snyk 以及其他 ASPM 供应商（如 Cycode、Apiiro 和 Ox）引入了检测和映射使用 AI 模型风险的功能，例如确定它们的依赖项和数据集。目标是防止篡改或无意的偏见，例如调整模型以在购物平台中偏爱特定产品。

简而言之，AI 态势工具旨在保护AI 系统的基础设施和生命周期，帮助组织识别、管理和强化其 AI 的动力来源。

应用程序运行时保护

运行时应用程序保护对于构建和部署自己 AI 驱动应用程序的公司最为相关。最初，许多这类应用程序是基本的聊天界面，安全风险极低。用户可以提问并获得答案，但 AI 未被授予访问任何敏感系统或数据的权限，只能访问提示词本身。

然而，今天的应用程序功能要强大得多。现代架构允许 AI 智能体访问内部系统、检索敏感用户数据甚至执行代码。这种转变极大地提高了 这些工具的风险状况，引发了安全负责人的一波担忧。

这里最常见的攻击类型是提示词注入，即诱使模型执行超出原定意图的操作。然而，也存在其他威胁，包括模型侦察 和隐蔽的偏见注入，这些可能更难检测。

作为回应，业界专注于两个关键领域：

• • 在运行时监控恶意活动
• • 在部署前测试AI模型以识别漏洞

这催生了一小批供应商，他们对 AI 模型进行安全测试，类似于 DAST 工具扫描 Web 应用程序的方式。这些工具在部署前探测模型的偏见、鲁棒性和抗攻击能力。

这也复兴了一种轻量级的RASP 风格 的 AI 应用程序保护，通过运行时监控代理来防范实时威胁。

AI 在安全领域的应用 (AI for Security)

虽然大多数安全工具都在为投资者描绘其 AI 故事，但我们还想强调那些从 AI 原生方法构建的初创公司，以及在 AI 采用方面领先的老牌公司。

AI 最擅长的是总结大量数据以供人类使用。因此，安全领域 AI 的大多数创新都集中在耗时的分析任务上。这主要在两个领域得以应用：用于事件分析的安全运营中心 (SOCs)，以及用于代码分析的应用程序安全。

在这两种情况下，当 AI 能够访问所有相关数据时，它都表现良好。事实上，它通常能生成超越人类能力的总结，尤其是因为这些任务经常交给对涉及的全部技术、平台和工具了解有限的分析师。

因此，围绕AI 驱动的代码修复工具 和SAST 解决方案的开发激增。虽然我们在之前的报告中涵盖了 AI 自动修复工具，但本节重点介绍新兴的AI 原生代码扫描 类别。

从头开始利用 AI 构建的 SAST 解决方案特别适合发现与身份验证相关的漏洞以及其他传统扫描器经常遗漏的上下文感知问题。

鉴于大多数漏洞，尤其是 OWASP Top 10 中的漏洞，都与身份验证有关，并且传统静态分析难以检测它们，我们相信 AI 智能体将在应用安全扫描的未来扮演核心角色。

在安全运营 领域，AI 驱动的分析工具在演示环境中通常显得非常先进。然而，在实际使用中，结果好坏参半。SOC 中最常见的挑战之一是在调查过程中发现数据缺失。在这些情况下，AI 容易产生幻觉结论或生成缺乏可操作价值的分析，尤其是在无法访问关键日志或不熟悉的数据源时。

这就是为什么我们更喜欢那些所有数据已经集中化的解决方案，允许 AI 查询所需的一切以构建准确的调查时间线。这里有两个值得注意的供应商是Exaforce 和AI Strike。两者都提供了强大的数据平台，将 AI 嵌入整个 SOC 工作流，从分析、检测工程到 SIEM健康度和优化。

最后一个值得强调的领域是漏洞管理。几家初创公司专注于使用 AI 来更好地组织或丰富现有数据。

两个很好的例子是Phoenix Security 和Opus Security（被 Orca Security 收购）。Phoenix 使用 AI 将 CWE 映射到漏洞，改进优先级排序逻辑。Opus 应用 AI 来支持数据关联和漏洞修复的高级工作流。一个值得提及的新进入者是Maze，它采用端到端的 AI 方法进行漏洞分析。

既然我们已经列出了 AI 安全的核心应用场景，让我们看看行业领导者的采用重点是什么。

AI 采用与安全需求

在明确了应用场景之后，我们对安全负责人进行了调查，以了解 AI 安全在其组织内的优先级情况。结果显示，大家开始逐渐关注 AI 风险，尤其是在应用开发方面。

受众报告第一部分 (Audience Reports Pt. 1)

强烈的探索性兴趣

受众报告第二部分 (Audience Reports Pt. 2)

受众报告第三部分 (Audience Reports Pt. 3)

老方案，新问题

例如，防火墙供应商已经迅速适应了基本应用场景，如监控员工 AI 聊天机器人使用情况并对批准的模型或终端强制执行访问策略。 同样，专注于 SaaS 安全或 DLP 的供应商已经为权限问题和敏感数据暴露提供了可靠的检测。话虽如此，像 VS Code 插件这样的监控工具仍然是一个弱点。开发人员工作站通常缺乏应用于其他终端的保护，并且密切关注 AI 驱动的编码工具对大多数企业来说仍然是一个悬而未决的挑战。

接下来，在 AI 安全态势管理 方面，传统安全供应商具有显著优势。许多已经与云环境集成并扫描工作负载，因此开始检测 AI 特定信号（如软件包使用、模型部署或暴露的 API）是合乎逻辑的一步。 然而，传统工具的一个不足之处是新兴的供应商（如 Noma）所瞄准的更广泛的数据安全领域，涵盖从模型部署到数据工程和生命周期管理的所有内容。

类似地，SCA 扫描器 已经提供了对软件包使用和依赖项的可见性。它们处于有利位置，可以识别正在使用哪些模型以及它们在代码库中的部署位置。

转向 AI 应用程序保护，重要的是要认识到大多数 AI 应用只是 SDK 和 API 调用的集合。这意味着传统的应用程序安全解决方案已经在向 AI 领域迈进，将其运行时保护功能构建到现有产品中。尽管如此，由于运行时应用程序保护相对较新，几乎每个人都仍处于追赶模式。

在基线层面，WAF 将演进以包含对诸如提示词注入 等行为的检测，尽管创建有效的规则将具有挑战性。这些攻击高度依赖于上下文，很难使用传统的基于签名的方法检测。

应用程序检测与响应 (Application Detection and Response, ADR) 解决方案特别适合处理 AI 应用程序的运行时保护，但目前专门的 AI 运行时工具在覆盖范围和检测准确性方面仍处于领先地位。

特别是，AI 安全测试正获得越来越多的关注，因为企业寻求了解并主动识别这些攻击实际上是如何发生的。

市场图谱与领导者

实施方案

在深入探讨具体的平台和工具之前，了解供应商用于实现其目标的不同实施方案非常重要。企业可见性和数据防泄露最常见的方法是通过浏览器或 IDE 插件 来监控员工对第三方聊天系统的使用。对于应用程序保护，通常使用 SDK 来实现围绕 AI 使用的可见性和保护。大多数统一工具并不完全提供完整的 SDK，因为它们在这个领域的产品较新，通常只提供基本的 API。

许多供应商还提供网络代理，将用户请求路由到批准的 AI 模型。该代理作为监控模型使用和检测风险提示词的前端。在许多情况下，这种架构还支持运行时应用程序保护，因为可以实时拦截和检查网络请求。

对于运行时应用程序保护，大多数供应商提供 API 以及 SDK（作为这些 API 的自定义包装器），开发人员可以将其集成到他们的应用程序中。这些 SDK 有助于监控提示词注入和其他攻击类型，同时还能在生产环境中部署 AI 功能之前启用测试功能。

最后，第三方集成 是数据防泄露和态势管理的常见功能。在 DLP 方面，这些集成通常专注于 Microsoft Copilot 等工具，实现对用户生成的 AI 应用的可见性和控制。在安全态势方面，供应商通常与 AWS 等云环境 集成，以识别正在使用的模型及其部署方式。一些工具还与 GitHub 等源代码管理平台 连接，以监控哪些 AI 模型嵌入在代码库中以及其具体位置。

权衡取舍

与安全领域的大多数其他类别一样，使用平台型供应商与专业型供应商相比存在权衡。 大多数平台型供应商的优势在于其拥有一个统一的检测引擎，可以覆盖终端用户检测和应用程序检测。此外，它们被视为大型企业的单一 AI 安全合作伙伴，专注于加速安全的 AI 采用。

统一化方案

例如，Prompt Security 和 Lasso 都提供浏览器插件 和终端代理来监控员工 AI 使用，以及一个网络代理 来重定向和检查 AI 流量。然而，与专用的应用程序运行时安全 (application runtime security) 供应商不同，它们不支持通过代码集成发现 AI，并且只提供最低限度的应用程序保护功能。

Palo Alto Networks 最近通过收购 Protect AI（主要专注于模型测试）进入了这一统一类别。 通过此次收购，Palo Alto 通过其网络安全产品以及为应用程序安全采用者提供的选项来提供 AI 安全。

拥有统一工具的价值取决于您的应用场景。总的来说，这些工具非常适合那些首先关注员工监控和敏感数据检测应用场景的公司。它们的产品在检测和阻止可疑或不必要的 AI 活动方面最为成熟。它们拥有强大的检测引擎，通过 SDK 和 API 使用扩展到开发者工作流选项。

广义上讲，这些平台旨在作为企业全面管理 AI 安全的长期合作伙伴。

终端用户数据管控

下面重点介绍的三家供应商 exemplify 了解决该问题的不同方法：Knostic、Zenity 和 Harmonic。需要说明的是，大多数统一供应商采取与 Harmonic 类似的方法。

Harmonic 专注于监控员工对 AI 的直接使用，无论是在聊天机器人、代码助手还是其他 AI 工具中。它通过浏览器扩展 和其他可以提供 AI 交互全面可见性的机制来监控 AI 交互。它们对不应共享给不同供应商的安全数据类型进行分类，然后警告或阻止用户发送该数据。

Zenity 最初是一个无代码安全平台，并且特别擅长保护内部开发的 AI 应用，例如通过 Microsoft Copilot 创建的应用程序。Zenity 监控这些应用程序的配置和运行时行为，使其非常适合那些启用内部 AI 开发而不引入沉重上手摩擦的组织。

Knostic 专注于 AI 使用的上下文数据访问。虽然它们不直接阻止或停止任何访问尝试，但它们基于应用场景构建权限模型，使得大规模部署 AI 安全解决方案更加可行。例如，确保只有 HR 员工可以询问有关薪酬的问题，

AI 安全态势管理

这里出现的一个较小的利基类别是 ML-BOM（机器学习物料清单），也称为 AI-BOM，工具。这个概念是传统 SCA（软件成分分析） 的自然延伸，专注于跟踪模型来源。由于许多模型要么是作为代码库导入，要么是直接安装在系统上，ML-BOM 旨在提供一种正式的方式来验证和报告正在使用的模型 及其来源。然而，我们预计这一类别最终将被更广泛的 SCA 功能所吸收，正如 Snyk 和其他 ASPM 采用该功能所表明的那样。

其他几家供应商也在试验 AI 驱动的态势管理。Rad Security、Codacy 和 JIT 都已经拥有成熟的平台，并迅速将 AI 技术整合到其基础设施和漏洞检测工作流程中。这些努力通常涉及围绕 AI 模型发现构建自动化，并将 AI 信号 嵌入到现有的安全态势工作流中。

在该领域的所有供应商中，Noma 作为最具前瞻性和创新性的供应商脱颖而出。安全团队目前对机器学习工作流 和数据工程师日常使用的工具可见性非常低。Noma 旨在保护整个数据工程工作流，为 Jupyter notebooks、Airtable 以及数据工程师用于移动和转换数据的许多编排机制提供保护。这种方法有潜力演变成专门版本的 DSPM（数据安全态势管理） 和 **ASPM（应用安全态势管理），以适应数据工程师独特的工作方式。

运行时应用安全

Pillar Security 是该领域的一个明显领导者，主要是因为它是一个开发者优先的工具。它首先与 GitHub 集成以实现发现，然后根据运行时洞察进行测试，最后通过其 SDK 提供保护。

Lakera 也凭借其广泛分享的 Gandalf 提示词注入测试游戏 强势进入市场，并随后将其平台发展成为最出名的 AI 应用安全运行时保护 解决方案之一。

随着 ADR（应用程序检测与响应） 供应商扩展到运行时 AI 保护领域，预计该领域的竞争将日益激烈。这些平台已经收集了监控运行时 AI 使用所需的大部分数据，并且在许多情况下，保护 AI 使用与保护任何其他形式的应用程序行为没有太大区别。

• • Oligo 披露了 PyTorch 和 AI 工作流中的早期漏洞——这些问题是其通过自己的监控工具监视可疑 AI 软件包活动而发现的。
• • Raven 和 Oligo 都专注于库级监控，最适合保护模型本身，特别是通过深入洞察 AI 相关软件包和依赖项。
• • 另一方面，Miggo 和 Operant 通过多个集成点 提供更广泛的覆盖范围，能够洞察数据流 (data flows)、API 调用 (API calls)，而不仅仅是库的使用。

随着市场的发展，运行时保护很可能成为企业 AI 安全战略的核心部分。赢家将是那些能够在深度模型感知与实用的应用级可观察性之间取得平衡的公司。

AI 在安全领域的应用

最好的例子是 Corgea（以及 DryRun 和 ZeroPath）。与许多其他正在试验自动修复等 AI 功能的 SAST 供应商不同，Corgea 重建了扫描 引擎，使用大型语言模型 (LLMs) 进行整个检测过程。虽然与 Semgrep（也支持自动修复）等供应商可能存在一些表面上的功能重叠，但 Corgea 的核心扫描架构 代表了一种根本性的转变 和类别的演进。

这种动态的另一个例子可以通过比较 Exaforce 与 Sysdig 或 Torq 等平台来看出。两者都使用 AI 来增强各种安全运营工作流，例如告警摘要和自动分析。这些功能虽然基础，但对于嵌入这些生态系统的从业者来说已经很有用。然而，Exaforce 提供了更深入、更全面的 AI 体验，延伸到检测工程、数据查询 和事件响应编排。

以上所有供应商都在利用 AI 进行创新，但展示了 AI 原生 (AI-Native) 和 AI 创新 (AI-Innovative) 方法之间的区别。

漏洞管理

最后一个值得提及的类别是漏洞管理 如何随着 AI 而演变。Opus Security（被 Orca 收购） 长期以来一直支持修复工作流程，但现在几乎所有流程都通过 AI 进行了增强，以协助进行优先级排序、分类和自动化。另一方面，Maze 采取了一种截然不同的方法，即由AI 处理漏洞调查和修复过程的每一步，从发现到优先级排序再到响应。

最令人兴奋的是观察我们是否会看到在 AI 之前和之后构建的工具之间出现明显的分界线，就像我们看到的向云原生工具的转变一样。

虽然这次技术架构可能不会发生那么巨大的变化，但越来越明显的是，用户体验 和数据交互模式已经发生了重大转变。

许多漏洞团队也在试验使用 AI 进行高级漏洞分析。例如 Phoenix Security 将 CVE 与 CWE 关联以进行漏洞利用预测，或关于该主题发表的各种学术论文。

工具购买流程图

做出购买决策

AI 安全领域任何工具购买决策的核心问题很简单：AI 使用给您的公司带来了多少风险？

这是一项特别难以评估的风险，因为 AI 相关风险往往变化迅速，只需一些微小但有意义的架构更改，风险就可能从可忽略不计变为非常重大。如果用户主要与启用了安全设置的标准聊天机器人交互，则风险相对较低。这些会话通常仅限于提供给模型的本地上下文，模型只是响应输入而不访问外部系统或数据。

然而，一旦允许 AI 智能体查找额外数据，风险就开始迅速升级，而当授予它们代表用户执行操作的能力时，风险就更大了。

一旦引入这些功能，风险状况就会发生巨大变化。 一个简单的身份验证失误就可能允许用户访问彼此的数据，暴露本应隔离的敏感信息。对于许多组织来说，包括即使是最先进的模型供应商，AI 智能体的身份验证和访问控制仍然是一个不断发展的挑战。

另一个需要考虑的因素是主要平台（如 OpenAI 和 Anthropic）的创新速度。这些工具正在快速添加功能，包括基本安全防护，虽然不如专用供应商的防护栏强大，但表明在模型层面对安全的日益关注。

那么，您应该在什么时候购买专门的 AI 安全解决方案？答案是：如果您在 AI 采用方面进展迅速并处理敏感数据，那么专业的工具可以为您的安全团队提供所需的可见性和控制力，以领先于新兴风险。

另一方面，大多数现有供应商正在快速添加 AI 相关功能，特别是对于更通用的应用场景。如果您的组织不在 AI 采用的最前沿，等待现有的供应商 提供您所寻找的功能是完全合理的，特别是如果您已经建立了稳固的供应商关系。

商 与适应其平台用于 AI 使用的现有供应商。

市场反思

以下是一些普遍性的总结：

AI 安全并不是一个独立的类别，而是将应用场景粘合在一起，这些应用场景与现代企业安全的几乎每个方面都有交集。从数据防泄露到应用程序保护再到基础设施态势，新风险的出现与新工具被引入来解决它们一样快。

AI 安全的独特之处在于攻击面变化的速度之快。一个单一的设计选择，比如让智能体访问内部数据或使其能够采取行动，就能将一个低风险场景转变为一个高风险场景。这种可变性意味着安全负责人需要密切参与 AI 采用对话，尤其是在团队从实验转向生产时。

好消息是，缓解 AI 相关风险的许多基础技术已经存在。现有工具通常可以扩展以覆盖早期应用场景，而专用解决方案在需要的地方提供专业深度。在两者之间进行选择不仅取决于您当前的架构，还取决于您的组织部署 AI 的积极程度。

最终，在这个新领域蓬勃发展的组织将是那些将 AI 安全视为其更广泛安全战略延伸的组织，建立在可见性之上，由上下文信息提供支持，并随时准备随着技术的发展而演进。

我们相信，从市场角度来看，DLP 应用场景将是寿命最短的。这就是为什么几乎每个从该类别起步的供应商后来都通过 API 扩展其终端检测，转向了运行时应用程序保护。大量的恐惧、不确定性和怀疑推动了面向终端的工具的初步采用，因为 CISOs 不信任像 ChatGPT 这样的工具。随着市场整合到少数聊天服务中，包括工作空间工具原生提供这些服务，信任已不再像以前那样是个大问题。从系统聊天中对个人身份信息 (PII) 进行脱敏处理，在安全意义上从未那么重要过。

与运行时 AI 应用程序相关的风险与日俱增，因为系统变得越来越复杂，用户要求他们的工具包含敏感数据查询。这里有一个有趣的波折，即行业如何意外地回归了运行时应用安全保护 (RASP)，因为大多数工具需要 SDK 才能获得检查恶意 AI 使用所需的洞察力。这使现有的 ADR 供应商处于有利的竞争地位。

AI 辅助编程的兴起也增加了对两种功能的需求：检测进行域名仿冒的恶意依赖项，以及获取开发者 IDE 的可见性。这将导致安全团队长期期望其 SCA 工具具有终端集成并能检测恶意软件包。

最后，根据早期的“AI 原生”原型，我们很可能看到工具发生类似云前和云后的转变。为 LLM 使用从头构建的应用程序的功能方式与传统应用程序完全不同，就像容器化应用程序的构建和部署方式通常与云计算时代之前构建的应用程序大相径庭一样。

一个悬而未决的问题是，像 OpenAI 和 Anthropic 这样的供应商会自己构建多少功能，这创造了一种类似于早期云时代的动态，当时安全工具对于基于 AWS 会自行构建多少功能而犹豫不决。安全团队需要在这些早期工具上投入多少，很大程度上取决于其组织的风险状况以及 AI 采用的速度。

总而言之，AI 显然将长期存在，而相关的安全问题才刚刚开始。

原文链接

https://pulse.latio.tech/p/2025-latio-ai-security-report